1. Technical Field
The field of the invention is mobile communications and, more particularly, to reporting of retransmissions from user equipment to a base station for use for instance by a serving radio network controller in outer loop power control.
2. Discussion of Related Art
The invention relates to the 3GPP (Third Generation Partnership Project) specification of the Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA) and more specifically to the Wideband Code Division Multiple Access (WCDMA) High Speed Uplink Packet Access (HSUPA) which is an enhanced uplink feature used in the Frequency Division Duplex (FDD) mode. This feature is being specified in the 3GPP and targeted to 3GPP release 6.
Referring to FIG. 1, the Universal Mobile Telecommunications System (UMTS) packet network architecture includes the major architectural elements of user equipment (UE), UMTS Terrestrial Radio Access Network (UTRAN), and core network (CN). The UE is interfaced to the UTRAN over a radio (Uu) interface, while the UTRAN interfaces to the core network over a (wired) Iu interface.
FIG. 2 shows some further details of the architecture, particularly the UTRAN. The UTRAN includes multiple Radio Network Subsystems (RNSs), each of which contains at least one Radio Network Controller (RNC). Each RNC may be connected to multiple Node Bs which are the 3GPP counterparts to GSM base stations. Each Node B may be in radio contact with multiple UEs via the radio interface (Uu) shown in FIG. 1. A given UE may be in radio contact with multiple Node Bs even if one or more of the Node Bs are connected to different RNCs. For instance a UEI in FIG. 2 may be in radio contact with Node B 2 of RNS 1 and Node B 3 of RNS 2 where Node B 2 and Node B 3 are neighboring Node Bs. The RNCs of different RNSs may be connected by an Iur interface which allows mobile UEs to stay in contact with both RNCs while traversing from a cell belonging to a Node B of one RNC to a cell belonging to a Node B of another RNC. One of the RNCs will act as the “serving” or “controlling” RNC (SRNC or CRNC) while the other will act as a “drift” RNC (DRNC). A chain of such drift RNCs can even be established to extend from a given SRNC. The multiple Node Bs will typically be neighboring Node Bs in the sense that each will be in control of neighboring cells. The mobile UEs are able to traverse the neighboring cells without having to re-establish a connection with a new Node B because either the Node Bs are connected to a same RNC or, if they are connected to different RNCs, the RNCs are connected to each other. During such movements of a UE, it is sometimes required that radio links be added and abandoned so that the UE can always maintain at least one radio link to the UTRAN. This is called soft-handover (SHO).
It has been agreed in 3GPP HSUPA standardization that the UE transmits RSN (retransmission sequence number) on E-DPCCH (enhanced-dedicated physical control channel) together with data transmission on E-DCH (enhanced-dedicated channel). Node B “knows” the redundancy version to be used from RSN. Node B can also adjust its retransmission counter based on RSN. Furthermore, it has been agreed that Node B reports the number of retransmissions (4 bit field is reserved in FP header) required to receive the block correctly to the SRNC. Outer loop power control (OLPC) can use this information to adjust SIR targets and power offsets of different channels.
The RSN is specified to be 2 bits, i.e., it can have values 0, 1, 2 and 3. It has been specified that RSN saturates to 3 even if there are more than 3 retransmissions, i.e., RSN takes values 0, 1, 2, 3, 3, 3 when there are more than 3 retransmissions. If a Node B misses (i.e., does not even receive E-DPCCH) first three (or more) transmissions (which may be typical in SHO case) but receives then, e.g., two transmissions (both with RSN=3), soft combines them and finally decodes the block correctly. Then Node B sends the correctly received block to SRNC and should tell to the SRNC the number of retransmissions required for this block. However, the Node B does not “know” when the transmissions of this block were started: it may have missed 3, 4, 5, etc. transmissions, in all cases RSN=3.
Concerning the “knowledge” of Node B, a problem occurs when the first transmission that Node B receives is with RSN=3, then Node B does not (necessarily) “know” when the first transmission was sent.
Node B is able to determine and therefore “knows” if it receives a transmission from UE with RSN=0, 1 or 2. Even if those are all incorrect and UE then retransmits with RSN=3 (one or several times), Node B can count, i.e., can calculate, the number of retransmissions.
Some examples follow:
UE transmits RSN:012333Node B receives:—1—3—3
In this example Node B can count that the actual number of retransmissions is five (after the first (RSN=0) transmission). A hyphen (-) indicates that Node B completely missed that transmission, i.e., could not decode RSN or E-DPCCH where RSN is sent; 1 above indicates that Node B received E-DPCCH correctly and read RSN=1 from there, but did not decode the data on E-DPDCH correctly and therefore requested retransmission; second and fourth retransmission was missed completely (even E-DPCCH); a third retransmission (RSN=3) was received and combined with retransmission 1 but the data was not yet correct; finally, a fifth retransmission when combined with the first and third retransmissions resulted in correct decoding of the data and an ACK was sent to the UE and correctly received data was sent to RNC (in FP data frame) and ‘Num of HARQ retrans’=5 (=0101) was reported in the FP header.
A second example follows:
UE transmits RSN:01233Node B receives:0——33
In this example Node B can count that the actual number of retransmission is four.
A third example follows:
UE transmits RSN:01233Node B receives:———33
In this third example Node B cannot necessarily count that the actual number of retransmission is 4, and it is therefore not necessarily able to accurately indicate the number of retransmissions in the FP header. If the number of transmissions is limited to say five transmissions (i.e., four retransmissions), then in the last case Node B knows that there has been 4 retransmissions and can report this. This is an example of why we cannot always rely only on RSN received from UE to decide whether Node B knows or not (i.e., there can be some additional information available (max number of transmissions in this example)).